home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0004-Re Comparing Object-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  6.1 KB  |  138 lines  |  [TEXT/GEOL]
  1. Item    4354982                         3-June-89        15:10
  2.  
  3. From:   MOOF                            Rollin, Keith A, APL
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    Re: Comparing Objects
  8.  
  9. Alan,
  10.  
  11. I'd like to address your idea on TObject.Compare. Keep in mind that I'm not one
  12. of the MacApp engineers, that these opinions are my own, and that they don't
  13. represent those of the MacApp programmers; I have no idea what merit they will
  14. find in your idea.
  15.  
  16. Overall, I'm afraid that I disagree with your approach. I think that the
  17. default comparison routine will tend to cause confusion, and I also think that
  18. a Compare routine is not appropriate for the base TObject object. I'll explain
  19. all of this below in comments interspersed with yours.
  20.  
  21. First of all, I think that your default compare method will cause more harm
  22. than good. Better would be for the Compare method to do nothing at all than
  23. what you suggest:
  24.  
  25. >    FUNCTION TObject.Compare(anObject:TObject):INTEGER;
  26. >        VAR p,q:LONGINT;
  27. >    BEGIN
  28. >    p:= LONGINT(SELF);
  29. >    q:= LONGINT(anObject);
  30. >    IF p < q THEN
  31. >        Compare:= kALessThanB
  32. >    ELSE IF p > q   THEN
  33. >        Compare:= kAGreaterThanB
  34. >    ELSE { p = q }
  35. >        Compare:= kAEqualB;
  36. >    END;
  37.  
  38. I feel that your method is not consistant. In order for a sort comparison to be
  39. of any use, I feel that it should produce consistant sorts and results every
  40. time. The way you have it set up, compares will be at the mercy of the Memory
  41. Manager, as it hinges on the location of the object's Master Pointer in memory.
  42. There is no guarantee that this location will be same every time you run your
  43. program.
  44.  
  45. > Such an implementation would require a minimal adjustment by making the
  46. > UList.p constants global and defaulting TSortedList.Compare(item1,item2) to
  47. > item1.Compare(item2).
  48. >
  49. >It would also allow easy compare methods for specialized objects. For example,
  50. > if someone had Finder-styled named objects, i.e. objects with a string field,
  51. > say TStrObject, one could override this Compare to produce
  52. >
  53. >     FUNCTION TStrObject.Compare(anObject:TObject):INTEGER;OVERRIDE;
  54. >        VAR p,q:Str255;
  55. >    BEGIN
  56. >    p:= TStrObject(SELF).fString;
  57. >    q:= TStrObject(anObject).fString;
  58. >    IF p < q THEN
  59. >        Compare:= kALessThanB
  60. >    ELSE IF p > q   THEN
  61. >        Compare:= kAGreaterThanB
  62. >    ELSE { p = q and the user didn't provide unique names }
  63. >        Compare:= INHERITED Compare(anObject);
  64. >    END;
  65.  
  66. Actually, I think that the current method of comparing in TSortedList is better
  67. for the scenario you present. Let's look at it another way. As you know, you
  68. can sort in different ways in the Finder windows. Two implement this, you could
  69. take the following two approaches:
  70.  
  71.     - have a case statement in your TYourSortedList.Compare routine that
  72.         looked at the type of sorting required (possibly stored in an
  73.         fSortType field) and make the appropriate comparisons.
  74.     - store a pointer to a comparison routine in an fSortProcPtr field of your
  75.         TYourSortedList object. The TYourSortedList.Compare routine could then
  76.         just call that routine. All you would have to do to change the
  77.         comparison criteria would be to change the pointer in that field to
  78.         some other global procedure.
  79.  
  80. On the whole, I think that it is better to have a list that knows something
  81. about objects, rather than an object that knows about lists.
  82.  
  83. >Perhaps the default TSortedList.Compare could even call, in debug mode,
  84. >something like GetEltType(item1).Compare(item2) so that such lists always have
  85. >a default sorting which, of course, can be still overridden.
  86.  
  87. I'm not quite sure what you're trying to do here. There is no GetEltType method
  88. that I know of, and even if there is, it seems to me that it would return an
  89. ObjClassID, not an object.
  90.  
  91. > My rationale for this is that Compare seems to be a property of objects, not
  92. > the lists which contain them; and that the above is a canonical content-free
  93. > way to compare such, which has the crucial property that aItem.Compare(bItem)
  94. > = kAEqualB if and only if aItem = bItem. Overrides can easily produce content
  95. > sensitive versions of this: aItem.Compare(bItem) = kAEqualB if and only if
  96. > "Content"(aItem) = "Content"(bItem) as in the TStrObject version above.
  97.  
  98. I'm afraid that I disagree with you here. Objects at a base level should not
  99. know about other objects. That is the whole point of object oriented
  100. programming. However, it is recognized that relationships must be maintained
  101. somewhere are sometime, so TLists and TSortedLists were created. It is the sole
  102. function of these objects to maintain those relationships, and, hence, it is
  103. they that should contain the comparison criteria.
  104.  
  105. This has the advantage mentioned above that the comparison criteria can be
  106. changed by merely  changing the list that the items are in. Otherwise, you will
  107. have to create a subclass for every type of comparison you want to support.
  108.  
  109. > Since I do not have 2.0ß9, I do not know if such a method has been
  110. > implemented. Since my in-depth knowledge of programming philosophy and
  111. > practices is limited, I cannot estimate all the ramifications of such a new
  112. > method. I would like to suggest this method though, and if the idea is dumb
  113. > find out why. [because I am seriously considering tweaking my MacApp to
  114. > include this method]
  115. >
  116. > If this idea is reasonable, the minimal code and documentation changes
  117. > required might make it a reasonable last minute inclusion for 2.0ß9. If
  118. > deadlines are long past [and the idea holds water], could it be considered
  119. > for the next release?
  120. >
  121. >    Alan    CDA0373
  122. >
  123.  
  124. Thanks for your ideas on this Alan. I'm sure that if others feel this way, then
  125. we'll soon have a lively discussion on this in MacApp.Tech$. For instance, I do
  126. think that a strong case could be made of a TObject.IsSame method that will
  127. determine if two objects are the same. A slightly shakier case could be made
  128. for TObject.IsEqual, as long as you compared the entire object, and not just
  129. some arbitrary key.
  130.  
  131. In the meantime, let us know if you have any other suggestions. All are welcome
  132. for MacApp 2.1!
  133.  
  134. - Keith Rollin
  135. - Apple Developer Technical Support
  136.  
  137.  
  138.